This page last changed on May 31, 2006 by tcarlson.

The Mule PicoContainer extensions provide ways of using PicoContainer and Nanocontainer with Mule.

Pico Component Resolver

This extensions allows the Pico container to be used like factory for the components that Mule manages. To make the Pico container accessible to Mule you must define the Component Resolver on the Model in the Mule configuration. For example,

<model name="muleModel">
    <component-resolver name="pico" className="org.mule.extras.picocontainer.PicoComponentResolver">
        <properties>
            <property name="configFile" value="../conf/pico-container-config.xml"/>
        </properties>
    </component-resolver>
    ...
</model>

Note that the only property on the PicoComponentResolver is 'configFile'. This value can be a reference to a one or more comma separated files on the local file system or a classpath resource. The classpath is checked first.

Once the resolver is set, Pico managed objects can be used as Mule components by setting the implementation attribute of a component to the Component key in the configuration i.e.

<mule-descriptor name="myMuleComponent"
    inboundEndpoint="jms://order.queue"
    inboundTransformer="JMSMessageToObject"
    implementation="myPicoComponent">
</mule-descriptor>

Pico Component Pooling

Like everything else the Component pooling implementation in Mule is pluggable. By default, Mule uses the Jakarta commons pool for pooling components however it is possible to plug in a Pico Pool (or any other) implementation. To use Pico for component pooling, you must configure the pool on the Model -

<model name="muleModel">
    <component-pool-factory className="org.mule.extras.picocontainer.PicoPoolFactory"/>
    ...
</model>

There is no real benefit of using Pico pool over the default implementation. However, users may find they want to change the behaviour of component pooling in Mule. This provides a good reference of how to do that.

Document generated by Confluence on Nov 27, 2006 10:27